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(54) System for digitally signing a document 

(57) The preferred embodiment of the invention 
comprises a computer system which employs a trusted 
display processor (260), which has a trusted processor 
(300) and trusted memory (305. 315. 335, 345) physi- 
cally and functionally distinct from the processor and 
memory of the computer system. The trusted display 
processor (260) is immune to unauthorised modification 
or inspection of internal data. It is physical to prevent 
forgery, tamper-resistant to prevent counterfeiting, and 



has crypto functions (340) to securely communicate at 
adistance. The trusted display processor (260) interacts 
with a user'ssmartcard (1 22) in order to extract and dis- 
play a trusted image, or seal (1000), generate a digital 
signature of the bitmap of a document image and control 
the video memory (315) so that other processes of the 
computer system cannot subvert the image during the 
signing process. The user interacts with the trusted dis- 
play processor via a trusted switch (1 35). 
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ate signing is in fact the document they are signing. 
Rflfikdround Art 

such transactions. . amec are aimed at increasing the security and trustworthiness 

market whch Mud. a ^.^a^SS^entiona. persona, computers, and 

computer. Presently, such smartcards are at the tevelc* Deng auo schemes go some way to 

in some cases are integrated into a casing of f h ^<«^^^^^,hte8S gained by prior art schemes 
improving the security ol computer P^^^^^^^^Z^^s between computer plat- 

wTeguire greater confidence in the ^^^V^'KC^orm- 99301100.6. «ed a, the Eu- 

ropean PaieniOfl.ce on 15 February 1999 ^ ife « which are incorporated herein by 

9905056.9. filed ^^^^^^^^^ a computing piatlorm which has 

c^r^^ 

trusted component is present, because: 

A user of a compute enlity has higher con*^ in the of his ow„ computer en,* and „ 

the integrity and security of the computer entity belonging to the other party. 
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• Each entity is confident that the other entity is in lact the entity which it purports lo be; 

• Where one or both of the entities represent a party to a transaction: e.g. a data transfer transaction, because of 
the in-buitt trusted component, third party entities interacting with the entity have a high degree of confidence that 

5 the entity does in fact represent such a party; 

• The trusted component increases the inherent security of the entity itself, through verification and monitoring proc- 
esses implemented by the trusted component; and 

w • The computer entity is more likely to behave in the way it is expected to behave. 

(0008] As has been indicated above, the conventional method of signing a document is to physically write a signature 
on the medium (usually paper) upon which an image of a document is reproduced. This method has the advantages 
that it is clear what is being signed, and the signed image is proof of what was signed. However, it does not meet the 
is needs ol e-commerce. 

{0009] Nowadays it is also possible to digitally sign a document, using a conventional computer platform and standard 
encryption techniques. In conventional computer platforms, however, the present inventors have appreciated that the 
electronic rendition of a document which is digitally signed is typically not the same rendition of the document that Is 
visible to the user. It is therefore possible for a user to unintentionally sign data that is different from that which he 
20 intended lo sign. Conversely, it is also possible lor a user to intentionally sign data and later fraudulently claim that the 
signed data does not correspond to that displayed to him by the computer platform. Such problems would still be the 
present, even if a trusted platform, as described above, were used. 

[0010] Conventional electronic methods of signing are well known to those skilled in the art. Essentially, digital data 
is compressed into a digest, for example by the use of a hash function. Then that digest is encrypted by the use of 

3S some encryption method that has been initialised by a secret key (or simply a 'secret 1 ). This is normally done on a 
computer platform, such as a PC. One implementation is to sign data using a private encryption key held secret on a 
user's smartcard, which is plugged into a smartcard reader attached to the computer platform. In the specific case of 
a textual document, the digital data may be the file produced by a word processor application, such as Microsoft's 
Notepad, Wordpad. or Word. As usual, the act of signing implies that the signer accepts some legal responsibility for 

jo the meaning of the data that was signed. 

[0011] Hash functions are well-known in the prior art and comprise one way functions which are capable of generating 
a relatively small output data from a relatively large quantity of input data, where a small change in the input data results 
in a significant change in the output data. Thus, a data file to which is applied a hash function results in a first digest 
data (the output of the hash function). A small change e.g. a single bft of data in the original data file will result in a 

3S significantly different output when the hash function is reapplied to the modified data file. Thus, a data file comprising 
megabytes of data may be inpul into the hash function and result in a digital output of the order of 128 to 160 bits 
length, as the resultant digest data. Having a relatively small amount of digest data generated from a data file stored 
in the reserved directory is an advantage, since it takes up less memory space and less processing power in the trusted 
component. 

40 [0012] During known signing processes, a user will typically interpret a document as it has been rendered on the 
computer's monitor at normal magnification and resolution. In existing applications, the user's smartcard signs data in 
a format that is the representation of the document by the application used to create anoVor manipulate the document. 
The present inventors believe, however, that there is potential for software to send data to the smartcard that has a 
different meaning from that understood by the user when viewing the screen. This possibility may be sufficient reason 

*s to introduce doubt into the validity of conventional methods of digitally signing electronic representations of documents 
that are to be interpreted by people. 

Disclosure of the Invention 

so [001 3] The invention consists of system;' and methods to improve confidence in digitally signed documents that are 
to be interpreted by people. They necessarily involve the reliable display ol data, which can be used for other purposes. 
[0014] In accordance with a first aspect, the present invention provides a data processing system arranged to gen- 
erate a digital signature representative of a document, the data processing system comprising: 

£5 main memory means for storing a document to be digitally signed; 

main processing means for executing at least one application process comprising means to generate graphics 
signals for displaying the document; 

means for generating a request signal for the document to be signed; 
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a display system comprising: 

signal, for generating a digital signature represents of the digrtal .mage data. 

SaSSSSSSSsasws 

li^Xa^andentoodlmento^ 
40 and drawings. 

Brief Descrip tion ol the Drawings 

[0027] Embodiments o. the present invention will now be descried in detail with re.erenoe to the accompanying 
45 drawings, ot which: 

Figure 1 is a diagram which illustrates a computer system suitable for operating in accordance with the preferred 
fat ?i ™^^ 

Rg'ureTteaftowdBgram which illustrates the steps involved in generate 
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Figure 7 is diagram which Hlustrates the sequence of messages between <he trusted display processor and the 
smart card in order to recover seal image data from the smart card; 

Figure 8 is diagram which illustrates the sequence of messages between the trusted display processor and the 
smart card in order to generate a signature of a document image; 
5 Figure 9 is diagram which illustrates the sequence of messages between the trusted display processor and the 

smart card in order to generate a signature of a summary of the document image signing process; 
Figure 1 0a is a diagram which illustrates an exemplary trusted image; 

Figures 10b to I0d are diagrams which illustrate the visual steps in signing a document image; and 
Figures 10e to I0g are diagrams which illustrate alternative ways of highlighting the image of a document to be 
10 signed. 

Best Mode For Carrying Out the Invention. & Industrial Applicability 

[0028] The preferred embodiment utilises a trusted component that most conveniently uses some of the character- 
is jstics of the trusted component' described in the applicant's co-pending European patent application number 
99301100.6. In that application, the trusted component is a hardware device, comprising a processor programmed to 
measure an integrity metric of its host computer, compare it with a true value of the integrity metric and communicate 
the integrity (or otherwise) of the host computer to users or other host computers. The significant similarities between 
that trusted component and the trusted component in the preferred embodiment herein are: 

20 

that they both use cryptographic processes but preferably do not provide an external interface to those crypto- 
graphic processes; 

that they are both tamper-resistant or tamper-detecting, so that their operation cannot be subverted, at least without 
the knowledge of the legitimate user; and 
26 that they both preferably consist of one physical hardwaro component that is both physically and functionally in- 

dependent of the host computer on which it resides. 

[0029] Such independence is achieved by the trusted component having its own processing capability and memory. 
[0030] Techniques relevant to tamper-resistance are well known to those skilled in the art of security, as described 

30 in the applicant's co-pending application. These techniques include methods for fabricating components to resist tam- 
pering, methods for detecting tampering, and methods for eliminating data when tampering is detected. It will be ap- 
preciated that, although tamper-proofing is a most desirable feature of the present invention, it does not enter into the 
normal operation of the invention and, as such, is beyond the scope of the present description. 
[0031] In this description, the term trusted 1 , when used in relation to a physical or logical component or an operation 

35 or process, implies that the behaviour thereof is predictable under substantially any operating condition and highly 
resistant to interference or subversion by external agents, such as subversive application software, viruses or physical 
interference. 

[0032] The term *host computer' as used herein refers to a data processing apparatus having at least one data 
processor, at least one form of data storage and some form of communications capability for interacting with external 
*o entities, such as peripheral devices, users and/or other computers locally or via the Internet. The term 'host computer 
system' in addition to the host computer itself includes standard external devices, such as a keyboard, mouse and 
VDU, that attach to the host computer. 

[0033] The term 'document 1 , as used herein, includes any set of data that can be visualised using a host computer 
system. Commonly a document will be a textual document, such as a contract However, a document may comprise 
4S graphics, or pictures, instead of, or as well as, text. In general, a document may comprise a single page or multiple 

pages. 

[0034] The term 'pixmap', as used herein, is used broadly to encompass data defining either monochrome or colour 
(or greyscale) images. Whereas the term 'bitmap' may be associated with a monochrome image only, for example 
where a single bit is set to one or zero depending on whether a pixel is 'on* or 'off, 'pixmap* is a more general term, 
50 which encompasses both monochrome and colour images, where cotour images may require up to 24 bits or more to 
define the hue, saturation and intensity of a single pixel. 

[0035] As will become apparent, the trusted component according to the preferred embodiment herein provides a 
secure user interface and, in particular, controls at least some of the display functionality of its host computer. The 
trusted component herein may or may not also acquire integrity metrics according to the trusted component in appli- 
es cant's co-pending patent application, although such acquisition of integrity metrics will not be considered herein. 

[0036] In essence, the preferred embodiment enables a user to digitally sign a document stored on a host computer 
using the private key of the user's smartcard, or other form of secure token such as a cryptographic co-processor. The 
signing is enacted by a trusted display processor (i.e. the trusted component) of the host computer under conditions 
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r^C Figure 2 shows a unit (CPU) 200. or ma* proc- 

[0040] According to F.gure 2. the host computer 100 ^^ p ^ 8 ^ ; |M ^ 8reTOunte d«ian»therboard 
^c^nnectedtomanmen^ cpu fe €eMi via a pc, 

215 of the host computer £j ,!7pc, bus^S To wE^ttached the other main components 

(Peripheral Component Interconnect) bndge 220 to a PCI bus ^° wn^cn a will not be 

ol the host computer 100. The bus 225 comprises appropnate control. ^ reM J"™^* ^ te bevond 

100411 The other main components of the host computer 100 attached to the ^ !^_n^ dliv ' 24S . 

be of the plugin type. ^ . irfl - t . tm<5ted disolav orccessor 260. In accordance with 

ss a most elegant and convenient solution. 

[0044] According to Figure 3, the trusted display processor 260 comprises. 

a microcontroller 300; 
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non-volatile memory 305, for example flash memory, containing respective control program instructions (i.e. 
firmware) for controlling the operation of the microcontroller 300 (alternatively, the trusted display processor 260 
could be embodied in an ASIC, which would typically provide greater performance and cost efficiency in mass 
production, but would generally be more expensive to develop and less flexible): 
s an interface 310 for connecting the trusted display processor 260 to the PCI bus for receiving image data (i.e. 

graphics primitives) from the CPU 200 and also trusted image data from the smartcard 122, as will be described; 
frame buffer memory 315, which comprises sufficient VRAM (video RAM) in which to store at least one full image 
frame (a typical frame buffer memory 315 is 1-2 Mbytes in size, for screen resolutions of 1280x768 supporting up 
to 16.7 million colours); 

10 a video DAC (digital to analogue converter) 320 for converting pixmap data into analogue signals for driving the 

(analogue) VDU 105, which connects to the video bAC 320 via a video interface 325; 
, an interface 330 for receiving signals directly from the trusted switch 135; 
volatile memory 335, for example DRAM (dynamic RAM) or more expensive SRAM (static RAM), for storing state 
information, particularly received cryptographic keys, and for providing a work area for the microcontroller 300; 

is a cryptographic processor 340, comprising hardware cryptographic accelerators and/or software, arranged to pro- 
vide the trusted display processor 260 with a cryptographic identity and to provide authenticity, integrity and con- 
fidentiality, guard against replay attacks, make digital signatures, and use digital certificates, as will be described 
in more detail below; and 

non-volatile memory 345 : for example flash memory, for storing an identifier l DP of the trusted display processor 
to 260 (lor example a simple lext string name), a private key Sqp of the trusted display processor 260, a certificale 

Cert DP signed and provided by a trusted third party certification agency, such as VeriSign Inc., which binds the 
trusted display processor 260 with a signature public-private key pair and a confidentiality public-private key pair 
and includes the corresponding public keys of the trusted display processor 260. 

2S [0045] A certificate typically contains such information, but not the public key of the CA. That public key is typically 
made available using a 'Public Key Infrastructure 1 (PKI). Operation of a PKI is well known to those skilled in the art of 
security. 

[0046] The certificate Certop is used to supply the public key of the trusted display processor 260 to third parties in 
such a way that third parties are confident of the source of the public key and that the public key is a part of a valid 
30 public-private key pair. As such, it is unnecessary for a third party to have prior knowledge of. or to need to acquire, 
the public key of the trusted display processor 260. 

[0047] The trusted display processor 260 lends its identity and trusted processes to the host computer and the trusted 
display processor has those properties by virtue of its tamper-resistance, resistance to forgery, and resistance to coun^ 
terfeiting. Only selected entities with appropriate authentication mechanisms are able to influence the processes run- 

*s ning inside the trusted display processor 260. Neither an ordinary user of the host computer, nor any ordinary user or 
any ordinary entity connected via a network to the host computer may access or interfere with the processes running 
inside the trusted display processor 260. The trusted display processor 260 has the property of being 'inviolate'. 
[0048] Originally, the trusted display processor 260 is initialised with its identity, private key and certificate by secure 
communication with the trusted display processor 260 after It is installed onto the motherboard of the host computer 

•to 100. The method of writing the certificate to the trusted display processor 260 is analogous to the method used to 
initialise smartcards by writing private keys thereto. The secure communications is supported by a 'master key*, known 
onfy to the trusted third party (and to the manufacturer of the host computer 100), that is written to the trusted display 
processor 260 during manufacture, and used to enable the writing of data to the trusted display processor 260. Thus, 
writing of data to the trusted display processor 260 without knowledge of the master key is not possible. 

•& [0049] It will be apparent from Figure 3 that the frame buffer memory 315 is only accessible by the trusted display 
processor 260 itself, and not by the CPU 200. This is an important feature of the preferred embbdiment, since it is 
imperative that the CPU 200, or, more importantly, subversive application programs or viruses, cannot modify the 
pixmap during a trusted operation. Of course, it would be feasible to provide the 6ame level of security even if the CPU 
200 could directly access the frame buffer memory 315, as long as the trusted display processor 260 were arranged 

&o to have ultimate control over when the CPU 200 could access the frame buffer memory 315. Obviously, this latter 
scheme would be more difficult to implement 

[0050] A typical process by which graphics primitives are generated by a host computer 100 will how be described 
by way of background. Initially, an application program, which wishes to display a particular image, makes an appro- 
priate call, via a graphical API (application programming interface), to the operating system. An API typically provides 
55 a standard interface for an application program to access specific underlying display functions, such as provided by 
Windows NT™, for the purposes of displaying an image. The API call causes the operating system to make respective 
graphics driver library routine calls, which result in the generation of graphics primitives specific to a display processor, 
which in this case is the trusted display processor 260. These graphics primitives are finally passed by the CPU, 200 
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storing the pixmap data into the frame bu «^ m f^ 0 Jf ' obrmao data from the frame buffer memory 31 5. con- 
to display the required image on the screen. 

interaction with the cryptographic processor andthe ^'J*™™™;^ ^ d „. host computer 1 00; the 

an image. <srW ^ Himent relie8 ^ interaction between the trusted display processor 

l0 0S4] As already mended the %f£££S£Z* "i— 6uitebte tor * aCC °' danCe !*£ 
260 and the user's smartcard 122. The processing engi nomnrises a orocessor 400 for enacting standard 

pre.erred embodiment is illustrated in Ffcure ^'^^^^J^^ signatures received from 
Encryption and deception « «o ^^^l whichZ a bu|t-« opera,*, 
elsewhere. In the present e ^ men \ me P r ~* 6 ^ " rid wja asynchronous protocols specified through ISO 
system and is arranged to communicate w*h the ^^J^^^^^^ 4 20. lor example flash 
7816-3, 4, T=0. T=1 and T=14 standards. The T „Sd loTdigtaiy signing data, and a 

memory, containing an identifier ^ M mrt^ ^^^^^Zn^Z^^ 
certificate Ce rtsc . provided by a trusted th.rd party ce *^™ ^ in ^un* Ihe certificate Certop 

key pairs arulindudes me cones^gpublrckeys^ 

of ihetrusted display processor ^^^^^^^^^lot^^t^ap^^ 
which can be represented i'SSSSi ln the present embodiment, the sea. 

operating securely with the user's smartens wrtl be descnb« hj < * bytneuse rasa urique identifier, for 

data SEAL is in the lorm of an ^2^^122 using well-known techniques. The processor 
example an image of the user hrmsetl. ^J^"^^„J^ state ^formation (such as received keys) 
400 also has access to volatile memory 430. *JZ^J?*£^ J, example electrical contacts, tor commu- 
and providing a working area for the processor 400. and an ntertace 440. tor examp 

nfcating with a smart card reader. amoU nts of memorv if stored as prxmaps. This may be a distinct 

[0055] Seal images can consume relatively ^J*™™* 0 ]™™^ smartcard 122. where memory capacity is 
disadvantage in circumstances ^^^f"^^ e^^elamTec^^es. For example, the sea. 
relatively limited. The memory r ^^^^ fc 7^^ de ^ e8 sed by the trusted display processor 260; a 
image could comprise: a compressed irmge^h ^ ^^^ ^ b „. truste d display processor 
thumb-nail image that lorms the pr.mrt.ve element of a ^^J^* ^ ^ be displayed by the trusted 
260; a naturally compressed image, ^hasa « £*«unM «J , n any of Le alternatives, 

display processor 260 as a smgle large rmage. or used as a « 9> _ ^ Mwe 

the sell ctetattse^ 
i.eanbe displayed. A,,^^^^^ 

images stored by the host computer 100 or a "«£*^* n ™ ^eve and display the correct image. Further. 

processor 260 and the smartcard 122. in the context or °™ c ""f 22 functions the functions are represented 

ration into host computer 100. trusted display P^^.-^SS^SSS Jl processes which take part 
indeper^ntly me physical a^« « 
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sented in ovals, and the 'permanent 1 data (including the document image lor the duration of the signing process), on 
which the functions act, are shown in boxes. Dynamic data, such as state data or received cryptographic keys are not 
illustrated, purely for reasons ol clarity. Arrows between ovals and between ovals and boxes represent respective 
logical communications paths. 

5 [0057] In accordance with Figure 5, the host computer 100 includes: an application process 500. for example a 
wordprocessor process, which requests the signing of a document; document data 505; an operating system process 
510; an API 511 process for receiving display calls from the application process 500; a keyboard process 513 for 
providing input from the keyboard 110 to the application process 500; a mouse process 514 for providing input from 
the mouse 1 1 5 to the application process 500; and a graphics primitives process 51 5 for generating graphics primitives 

io on the basis ol calls received from the application process via the API 511 process. The API process 511 . the keyboard 
process 51 3, the mouse process 51 4 and the graphics primitives process 515 are build on top of the operating system 
process 510 and communicate with the application process via the operating system process 510. ' 
[0058] The remaining functions of the host computer 100 are those provided by the trusted display processor 260. 
These functions are: a control process 520 for co-ordinating all the operations ol the trusted display processor 260. 

is and for receiving graphics primitives from the graphics primitives process and signature requests from the application 
process 500; a summary process 522 for generating a signed summary representative of a document signing procedure 
in response to a request from the control process 520; a signature request process 523 for acquiring a digital signature 
of the pixmap from the smartcard 122; a seal process 524 for retrieving seal data 540 from the smartcard 122; a 
smartcard process 525 for interacting with the smartcard 122 in order to enact challenge/response and data signing 

so lasks required by the summary process 522, the signature request process 523 and the seal process 524; a read 
pixmap process 526 for reading stored pixmap data 531 and passing it to the signature request process 523 when 
requested to do so by the signature request process 523; a generate pixmap process 527 for generating the pixmap 
data 531 on the basis of graphics primitives and seal image data received from the control process 520; a screen 
relresh process 528 for reading the pixmap data, converting it into analogue signals and transmitting the signals to the 

2S VDU 1 05; and a trusted switch process 529 for monitoring whether the trusted switch 1 35 has been activated by the 
user. The smartcard process 525 has access to the trusted display processor's identity data bp. private key Spp data 
and certificate Certop data 530. In practice, the smart card and the trusted display processor interact with one another 
via standard operating system calls. 

[0059] The smartcard 1 22 has: seal data 540; a display processor process 542 for interacting with the trusted display 
30 processor 260 to enact challenge/response and data signing tasks; smartcard identity data Iqc. smartcard private key 
data Ssc and smartcard certificate data Certsc 543. 

[0060] A preferred process for signing a document using the arrangement shown in Figures 1 to 5 will now be de- 
scribed with reference to the flow diagram in Figure 6. 

[0061] Initially, in step 600, the user controls the application process 500 to initiate a Signature request* for digitally 
35 signing a document. The application process 500 may be realised as a dedicated software program or may be an 
addition, lor example a macro, toa standard word processing package such as Microsoft's Word. In either case, neither 
the signature request nor the application process 500 need to be secure. When the user initiates the signature request, 
he also specifies the document to be signed, if it is not one which is already filling the whole screen. For example, the 
document may be displayed across a part of the full screen area or in a particular window Selection of a particular 
40 area on screen is a simple task, which may be achieved in several ways (using a WIMP environment), for example by 
drawing a user-defined box bounding the area or by simply specifying co-ordinates. 

[0062] Next, in step 602, the application process 500 calls the control process 520 to sign the image that Is being 
displayed (within a defined area or window) on the screen; the control process 520 receives the call. In parallel, although 
it is not shown, the control process 520 receives any graphics primitives from the graphics primitives process and 

45 forwards them onto the generate pixmap process 527. The call from the application process 500 to sign a document 
includes the co-ordinates (a.b.c : d) ol the edges of the document. Note that this sending of coordinates generally 
enables the signing of the entire surface of the screen, a complete window, or ol an arbitrary part of the screen. The 
application process 500 then waits lor lhe control process 520 to return the signature of the image. 
[0063] In response to the signature request, in step 604, the control process 520 forces the image that is to be signed 

«> to be 'static 1 from the time of the request until the process has been completed. Herein, 'static* means that the document 
image cannot be modified other than by the trusted display processor 260. This is so that the user can be certain that 
what he sees is what he is signing at all times during the process. In the present embodiment, the control process 520 
achieves a , 6tatic , display by 'holding-ofl, or not processing, any lurther graphics primitives. In some situations, the 
graphics primitives process (or equivalent) may 'buffer' graphics primitives until the control process 520 is ready to 

55 receive further graphics primitives. In other situations, graphics primitives for the image to be signed may simply be 
lost. Where the document image fills the whole screen, making the image static is simply a case not processing any 
graphics primilives. However, where the image to be signed forms only a subset, for example a window, ol the full 
screen, the control process 520 needs lo determine whether received graphics primitives would affect the 'static* area. 
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while the document image is static. process 520 instructs the generate 

[0064] Once the document .mage has been made state, in step application process 500. to modify 

pixmap process 527. eluding * ^^^^^'^^^^^ «h reference to Figure 
the pixmap to highlight the document tote signed as wi be ° e f°"^ " ^ fea(Jer 120 , as determined by 

10c. Then, in step 608. if a smartcard 122 e not already inserted I h ' graphica , 

the smart card process 525. ^l^c^ 
message asking me user to insert his sn^c^^^^ 

COUNT. .» the countdown timer expires ^*2J^ a JS£JL , 0 ,he applteation process 500. In ■ 

Uartcard process 525. to recover the seal data 540 ^"T^S 0 ^SS' r<^£ of me sea. data 540 
the generate pixmap process ! »JM«M Z££^« ^*P* Processor 260 and the 
is being attempted. £ ^^J^^^SSSStU we« known, •cha.tengeyresponse' techniquesto 
display processor process 542 1 ot the smartcard ^ ^ncard and back to the control process 520. The 
enact mutual authentication and pass the seal data 540 ! "»^2!S5mS £e described wHh relerence to 
details of the mutual authentication process and passing of the seal data 540 will now oe oescr. 

According to Figure 7. the smartcard process 525 sends a request REQ1 to the s^rtcard J* 
SXJSTK. l£*p* prccessor ^ J^^^S^l " wi^.C 
smartcard process 525. The smartcard process 525 generates a 0< ^ e ^ H ^ 
thoconcatonaticnR^w^ 

a 'replay attack-) by untrustworthy Processes. „ ^ concatenates Ffe with its seal data SEAL 540. 

[0068] The display processor process 542 of the smartcard «™<2Z" sS-.RJISEAL), encrypts the seal 
signs he concatenation R 2 IISEAL using its private key ^■^^tS^EAL) and sends nonce R* the 
data SEAL 540 using its private key Ssc to 

p«rr^^ 

524. to the control process 520. _,„-.«. eon receives the seal data SEAL 540. it forwards 

[0069] Retumingto Figure 6. in step622. when the ^^^f^^^^ generate a seal image 
L date to .he generate pbcmap process 527 ^kTw^rSem Sre 10d. Then/5, 

and use i. to highlight the document to be signed, as will be f^^^S^^sJ^ the user asking 
step 624. the con.ro. process 520 instructs the generate pocma , process J^JJJJ 8econd countdown 

whether they wish to continue wtth the signing operate. . n» ™- TT — 7' M from the user, the 

,imer COUNT, It me countdown .knerexpires. * s.ep 626, ^ a ^^^? iQ U3e application process 
control process ^JV^^S^ ^ ££Z - rntsaga Hep 629. ... * step 6*>. .he 

500. In response, the application process sou ™«P»£V " -T^lL the len secon d time limit, the process continues, 
user responds positively by actuating the trusted swrtch 1 35 wrthm *eton8«ond . arm . . P 

Theerfh^toconfinuecouH^ 

of the document image; the signature request process S^^^SSSaSU* the respective pixmap 
Oigestotthep^datao^^ 

data, uses a hash algorrthm to generate a digest D P « « me p " c[) information 

process 523. Mdtiona*. the read pixmap process 526 generates display format dala PP. wncn mc 
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necessary to reconstruct the image from the pixmap data into a text-based document at a later time (FD is not essential, 
since the document text may not need to be reconstructed), and returns this also to the signature request process 523. 
For example, the display format data FD may include the number of pixels on the screen surface and their distnbution. 
such as '1024 by 768\ and the font type and size used for the text (if the document is text-based) in the document (at 
5 least some of this information may instead, or in addition, be contained in a document 'summary . as wiU be described 
below). In steps 634 and 636, the signature request process 523 interacts with the display processor process 542 of 
the smartcard 122 using well-known challenge/response processes to generate an individual signature of the docu- 
ment, as will now be described in detail with reference to the flow diagram in Figure 8. 

[0071] According to Figure 8, the smartcard process 525 generates a request REQ2 for the smartcard 1 22 to generate 
10 a signature of the digest D PIX and display format data FD. The display processor process 542 of the smartcard 122 
responds by generating a nonce R3 and sending it to the smartcard process 525 with a challenge to return the digest 
D PIX and the display format data FD. The smartcard process 525 concatenates the digest Dp, x with the display format 
data FD and nonce R 3 , and sic/is the concatenation Dp^HFDIIRa to produce a signature sSopPpixllFDIIRg). The 
smartcard process 525 then sends the concatenation D PIX IIFDIIR3 and its respective signature sSopfDpKUFDIIRa) to 
is the display processor process 542 of the smartcard 122. The display processor process 542 uses the trusted display 
processors public key (which it has already received in the seal data 540 exchange) to verify the trusted display 
processor's signature sS 0P (D Plx llFDIIR3) and nonce R 3 , to prove that the digest is the current image digest. The display 
processor process 542 signs the digest of the pixmap D PIX and the display format data FD. using Its private key, to 
produce two signatures sS sc (D P , x ) and sSsc(FD) respectively. The display processor process 542 of the smartcard 
20 then returns the signed digest sSsc(Dp, x ) and signed display formal data sSsc(FD) to the smartcard process 525 ol 
the trusted display processor 260. The smartcard process 525 next verifies the digest D PIX and display format data 
FD, using the smartcard's public key (which it already has as a result of the seal data 540 exchange), and verifies the 
smartcard's signature, to prove that the smartcard is still online. 

{0072] Returning to Figure 6, in step 638, the smartcard process 525 of the trusted display processor 260 concate- 
25 natos tho pixmap PIX. the smartcard's signed versions of tho pixmap digest sS^D^) and display format data sSsc 
(FD) to form an individual signature PIXIIsSscfDprxJHeSsctFD) of the image, and returns it, via the signature request 
process 523. to the control process 520, which returns the individual signature to the application process 500. The 
application process 500 stores the individual signature, in step 640, and responds with a further call to the control 
process 520 to 'summarise the signing* operation in step 642. The purpose of a summary is to complete the signature, 
30 as will be described with reference to the flow diagram in Figure 9 and also the example summary below: 

1 TC-88503-00.01 

2 Access time: Thu 06-May-1999, 11: 18 
35 3 Pages: 2 

4 IraageOl I 560 x 414 (187,190) [1024 x 768 J 

+G r4imOLqS/twYuIMskyL4uk3noOw3^ 
40 cY5rTC563klovOPTBI/IyqZPxRnic- 

I END SIGNATURE 

8 Image02 I 670 x 379 (201,228) 11024 X 768] 

9 BEGIN SIGNATURE - **" 

10 UVlw5Rgr5F0iAjvUW4GP28NKAA+^ 
7ZZV+4fFttuSgO2I4n5iB)cSEwtEj026ik/np6paq+01GQZhhJCbq80aX97Gmdg3AoBq4x+D 

hujmqkCJO+D26+x8kE24Z8YFXLPOI- 

II END SIGNATURE 

12 Summary signature: 
SO 13 BEGIN SIGNATURE 



46 
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14 ciZDZL2+41FsFci2cPjWF«fltkyXrfHB^ 
een2DWlZGjplEESNkhoZXj0kT5TYNv2ylYFk01SN+JVF09bmc9GdYLo/hSOWyYG/U29Mzqz 

ktaTdTqY/gPhlGajrSJGqRms+we/c- 

15 END SIGNATURE 

[0073] In step 644, the control process 520 calls the summary process 522 to generate a summary message SUM 
containing the number of images (two in the example summary above) plus the individual signatures of the images 

(lines 6 and 10 ol the example), a label identifying the trusted display device (line 1 in the example), the current time 



11 

BNSOCCIDc <EP 1055S89A1_I_> 



EP 1 055 989 A1 

and date (line 2 in the example) and a signed digest of the summary itsell (.he 14 in the exa mple* For ^ch 'n«ge 
,he summary also includes the size of the image in pixels (e.g. 560X414 for .mage ,1 ). the offset from the ongin.of the . 
screen in pixels (e.g. 187.190 lor jmage 1) and the display resolution in pixels (e.g. 1024x768 to • .mage 1). . _ 
^ Cstrmrory process 522 then generates a digest of the summary^ in step 646 and calls the smartcarj 
S P ^l525o1thetrusteddis P layprocessor260tointeractwiththesma rt c a rd122usingc^ 

to generate a signature of the summary digest D^. as will now be described with reference to Figure £ 
I007S] According to Figure 9. the smartca^^ 
asignatureofthedigest of the summary D^. The display processo, 

R 4 and sends it in a challenge to return the digest of the summary D SUM . The smartcard P^^ 00 "^ 6 "!!^ 
io the digest 0 SUM with nonce R4 and signs the concatenation D SUM HR4 to produce a signature ^ W^^™ 
smartcard process 525 ol the trusted display processor 260 then sends the concatenat.cn D^IIR,, and re^echve 
sionature sSno(D c , lu IIRa) to the display processor process 542. The display processor process 542 then venfies the 
uuCdis^^^ 

has from the seal data 540 exchange), to prove that the summary is the current summary. Next the deplay processor 

»s process 542 signs the digest of the summary D SUM using its private key and sends the s.gned digest sSsd D^,) » 
the smartcard process 525. The smartcard process 525 of the trusted display processor 260 venf.es the d.gest and 
verifies the smarteard's signature, using the smartcard-s public key. to prove that the smartcaid « stmonhne_ 
[00761 Returning to Figure 6. in step 652. the smartcard process 525 returns the summary SUM concatenated with 
!he signed digest of the summary sS^D^) (to form concatenation v « ,he ™* ^ 

20 522. Io the control process 520. and the control process 520 returns the summary SUMIIsSscPsum) lo Ihe application 

process 500. The application process 500 receives the summary in step 654. 

[0077] The individual signature and summary may be used by the application process 500. or any other process 
running on the host computer 100 in various ways outside the scope of the invention, including as proof of contract, 
for storage or lor transmission toother entities. , 

25 [00781 Finally in step 656. the control process 520 unfreezes the display, by recommencing receipt and processing 
of graphic primitives associated with the document image, and thereby in eBect returns control O (the d*ptey back ^ to 
the application process 500 or other application software. Alternatively, control may not be handed back to the appli- 
cation process 500 until the user actuates the trusted switch 1 35 again, typically in response to another user message 
which, this time, would not have a timeout period. This would give the user more time to review the state document 

30 image before returning the host computer to standard, non-trusted operation. 

[0079] In order to verify a signed document, both the individual signature PIXIIsS sc (D PIX )llsS sc (FD) and the sum- 
mary SUMIIsSscfJW must be verified. Such verification methods are well known to those skilled in the art of securrty 
For example. toe stature on the digest of the pixmap sS^D^) is verified using the public key of the use* wh«h 
is publicly available and preferably contained within a digital certificate Certsc supplied by a cert.ficat.on authonty. The 

as verified digest is then compared with a value obtained by recomputing the digest from the pixmap. where the d.ges1 is 
generated using a standard, well-known and defined hash function. If the match is exact the signature has been 
verified Other signatures, including the summary, are checked in the same way. 

[00801 A preferred method of enablhg a person to verify the wording of the signed document is to translate the 
pixmap back into an image. This requires an application, or indeed a trusted display processor 260. to toad thepocmap 
40 dataRXintotheframebuflermerr^ 

ISoaTl 6 ^staSs 8 ^ 

00821 In Ihe preferred embodiment, the seal data SEAL comprises a pixmap of a trusted image. For example, as 
shown in Figure 10a. the pixmap of the seal data 540 defines a 'smiley lace' 1000 Figure 10b illust jates an jmage 
*5 1005 of an exemplary document Docl to be signed, in a window 1010 ol the screen (not shown). As a first highlightuw. 
step, after the image has been made static but before the seal data has been received, the trusted display processor 
260 highlights the document to be signed by superimposing a frame 1020 around the document image 1005. as illus- 
trated in Figure 10c. Also, where a smartcard 122 is not present, a user message 1030 asking the user to insert hjs 
smartcard is displayed accompanied by a ten second countdown timer 1035. as also illustrated m 10c. Next 
when the smiley face pixmap image is retrieved from the smartcard 1 22. the trusted d,splay processor 260 «^HBhes 
the frame 1040 with multiple instances 1045. or a mosaic, of the smiley face, as shown .n Figure lOd. In addition as 
shown in Figure lOd. the trusted display processor 260 generates a further user message 1050. accompanied by a 
ten second countdown timer 1055. asking the user whether they wish to proceed with the signing process. This em- 
bellished frame 1040 both indicates to the user that the correct static image area is being acted on and provides the 
user with a high level of confidence that the trusted display processor 260 is fully in control of the signing process; the 
presence of the user's own seal image provides confidence to the user that the message has come from the trusted 
display processor 260 rather than from some other (possibly subversive) software application or hardware dev.ce. 
[0083] Figures 10e and 10g illustrate alternatives to the frame' visual effect illustrated in Figures 10c and lOd. In 
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Figure I0e, four single seal images 1060 are positioned at the corners of the static document image using the co- 
ordinates provided by the application process 500, to define the static image area. In Figure 10f, the static image is 
defined by modifying the background thereof to show a single seal image. In Figure 10g. the static image is defined 
by modifying the background thereof to show a mosaic of seal images. It is expected that the skilled reader will be able 
s to think of other visual effects by which the static image may be highlighted in the light of the present description. In 
addition, it may be desirable to include further status messages during the signing operation, for example 'Retrieving 
seal data 540 now....". "Generating document signature now....', etc. 

[0084] It will be appreciated that the trusted display processor 260 needs to be able to display the seal image(s) and 
the messages in the correct places on screen. Clearly, the seal image and the message images are temporary, to the 

w extent they appear during the signature process and disappear thereafter There are well-known, standard display 
techniques for overlaying a first image with a second image, thereby obscuring a part of the first image, then removing 
the second image and restoring the portion of the first image that had been obscured. Such technique* are used as a 
matter of course in normal windows environments, for example, where multiple windows may overlap one another. 
The trusted display processor 260 is arranged to implement one of more of these standard techniques for the purposes 

'5 of superimposing the seal image(s) and the message images over the standard display. 

[0085] In some scenarios, it may be that a document is too large to tit all at once onto the VOU 105 screen and still 
be easily read by a person. Obviously, for the present embodiment to be practical, it is essenlial that a user can very 
clearly read the document before signing It. Therefore, the document can be split Into multiple screen pages, each of 
which needs to be signed and cryptographically chained to the signature of the previous page, as will now be described. 

20 [0086] First, the application process 500 causes the image ol the first page to be displayed and makes a call to the 
trusted display processor 260 for signing as before. When the trusted display processor 260 returns the individual 
signature, instead of requesting a summary, the application process 500 instructs the trusted display processor 260 
to display the image of the second page and sign the image. Clearly, in this case, the trusted display processor 260 is 
arranged to support such a request by the application process 500. Only after all images have been signed and returned 

ss to the application process 500 does the application process 500 issue a request for a summary. Then, the summary 
includes the number of images that were signed in this mufti-page document, for example as illustrated in the two- 
page summary above. 

[0087] The first page in the multi-page document is signed in the same way as a single page, resulting in return of 
an individual signature. When subsequent images are presented tor signing, however, the trusted display processor 

30 260 recognises that they are part of a multi-page document because no summary request was received after the 
previous signature request As a result, the trusted display processor 260displays a different message, which requests 
permission from the user to sign a continuation page. In response, the user who is signing a multi-page document uses 
the same reliable permission channel as before (for example, the trusted switch 135) to confirm to the trusted display 
processor 260 that this page is associated with the previous page, and is also to be signed. When the trusted display 

ss processor 260 receives this multi-page confirmation, it concatenates the signature of the previous signed page with 
the pixmap of the current page, creates a digest of the concatenation, and sends that to the smartcard for signing. This 
is instead of sending a digest of just the current pixmap. This process cryptographically •chains' a subsequent page to 
the previous page, so that pages cannot be rearranged without detection, nor can intermediate pages be inserted or 
deleted without detection. _ u 

ao [0088] The validity of the first page may be checked in exactly the same way as a single page. The validity of sub- 
sequent pages is checked using the same method as for a single page, except that the digest of the current pixmap 
is replaced by the digest of the concatenated previous signature and current pixmap. 

[0089] It will be appreciated that there are many ways of cryptographically chaining a subsequent page to a previous 
page. Such ways will be obvious to those skilled in the art of security in the light of the present description. 
45 [0090] For added security, the image of each page of a multi-page document may be arranged to include the con- 
ventional footer 'Page x of y, where V is the number of the page and y is the total number of pages. This enables 
ready detection by a person of a truncated document simply by reading the document. 

[0091] A significant benefit of the present document signing scheme is that a signed document can be re-signed and 
countersigned. As such, it is preferable for the summary of a document to include an audit trail. There are many vari- 

so ations on re-signing and countersigning, although (obviously) an electronic integrity check should always be done 
before any further signing. At one extreme, the new signer could view, confirm and re-sign each signed image in turn, 
effectively replacing the original signature by a new one. This method could be used, for example, by a user signing 
a document prepared for him by someone else. At the other extreme, the new signer could simply •rubber stamp 1 the 
original signature by signing the original summary, without necessarily viewing the document at all. This could be useful 

&5 to a manager countersigning the work of a trusted employee. 

[0092] For a re-signing operation, the application process 500 issues a re-signing request, and transmits an already 
signed document (plus the individual signature(s) and the summary) to the trusted display processor 260. The trusted 
display processor 260 verifies the signed document using the public key of the signer, recovers the pixmap* of the 
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document (or each page of the document) and displays each verified image in the correct order to the newusenasfi 
fiSy Z original irnSes trom the signature request appficatton. The user confirms the acceptance of 
SeJorexLpleusfngatrustedswfichiaSasbefo.a.andcauees^ 

ISging to the new user. This results, in a signed document that is the same as the or.g.nal document except that rt 
has been signed by the smartcard belonging to the new user. r ^,.,» e , an H 
room Similarly, for a counter-signing operation, the application process 500 issues a countering request and 
transmits the signed document (plus indivfclual signatures and the summary) to the tested Replay P^^^Jhe 
rusted display processor 260 verifies the signed document and displays each verified .mage .n the correct order to 
Ih^nl us7as P if they were original images from the application process 500. The user -* = o^e ofea h 
individual image and the trusted display processor 260 signs the or.g.nal summary using foe smartcaidtelong^g to 
Z ne^user. Optionally the new user could provide a certificate of the previous user's public key. sgned by the new 
user, to ease the processing overhead associated withlater verification of the signature. _ _ 

[0094] Clearly, there are many possible variations on the theme of resigning and countersigning, which will De ap- 
parent to the skilled person in the light of the present description. _ . ^^hj-™, 
p09S] Since a document may have a htetory of signing, re-signhg and/or ^ter^gn^g foe 
conveniently provides audit information, which forms part of the document summary. This audit information aHows the 
suture hko^r of the document to be traced. The audi, information includes date about the P^ «^°' *• 
document and the actions taken by the new user to create the new state of the document The audit ^or^tion is 
signed by the trusted display processor 260. since the audit information must be independent of me mm ■ Theaudtt 
inLnaUon always conlains any previous summary informaUon (including the ^"^^^ 
by the previous signer). If the signed document has been created from scratch the identity label ^£ J™"*? 
display processor 260 is inserted as an audit root. The audit information preferably also includes an i^tjcn of wh^, 
individual images were viewed and confirmed by the new user, and whether the document was created from scratch, 
or was re-signed, or was countersigned by the new user. To create a summary including audit information, thesmartcard 
is sent a digest of tho audit information concatenated with the previously described contents of a 6un ^-* tto ™ 
a digest of just the previously described contents of a summary. The rest of the process . as P^ousty desc, J*L 
tOoL An enhancement to the process tor signing a document is that, pnor to signing the pixmap date, the trusted 
Kay processoT^O compresses the pixmap using a lossless compression algorithm so that the overheads associ- 
ated with storing and sending the individual signature are reduced. _ 
,0097] The pixmap may be compressed by standard compression algorithms, for example a codeword-based algo- 
rithm applying ,12-1 or L2-2 compression. Alternatively, a technique similar to OCR (optical character recognrton) may 
be 2 compress the pixmap. In this case, the situaton dirfers from conventional OCR in that tat 
been perfectly 'soanned-. albeit at a lower resolution than in conventional OCR The O 00 ^ 88 ^.^^ 
pixrnaVmay be generated by WotHnatching" to create an alphabet for the pixmap. construct.* .a pixmap of each 
Seethe a^et, J constructing a message using those characters. 

original pixmap. This means that the pixmap can been compressed to a new alphabet and a message written in that 
aphabe^^ 

roosai Another wav of reducing the size of the image pixmap is by representing the image as a pure black and white 
SS £2£ZZ a Sngte bit - set to zero or one - to define whether a pixel is black or while. ^ervnse. the 
2£E5 te repLeSed as a full colour image, w^ere each pixe. may typical require up to 

lor colour documents or irrtages. 

[0099] At any time, the document image may be converted back into a text-based document . sing " OCBjje 
process to reconstruct a standard digital textual representation of the document This technjque cannot Mi^nM 
signature, since the textual mapping may be incorrect, but can be used by the rece verof a *^^^°™ V *J\ 
it back into a standard digital textual representation (such as ASCII) for subsequent machine manipulation. In prefened 
embodiments, the trusted display processor 260 is equipped to enact OCR document recovery. 
[0100] To enact OCR. an OCR alphabet is generated in a standard fash.cn and « then matched to stored fonts and 
hence converted to a standard character set. As h conventional OCR, ambiguous ^es rnay be rete.ned as a 
pixmap and flagged for conversion by the user. (This is unlikely, particularly if font type and size inf ormatwn has been 
supplied in the display format date FD, because there is no error in the data.) in cases of extreme caution, the entire 
reconstructed document should be manually checked by a person against the view of the document thai the e.gner 

intended to sign. . ' 

roiOH Preferably all document reconstruction processes are done by processes that are trusted. 
0102 The preferred embodiment described above relies on the premise *^^«*^^™J^£* 
direct and exclusive access to video date stored in the frame buffer memory 315. beyond the pom where the vrteo 
data can be manipulated by host computer 100 software, including the operating system. This implies that the vxleo 
data cannot be modified unless ihe trusted display processor 260 makes the modification. 
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[01 03] It will be appreciated that not all computer architectures are arranged in this way. For example, some computer 
architectures are arranged such that the frame buffer memory forms a pan of the main memory, thus formng a s.ngle 
address space (SAS) display system. One benefit of such a system is that both the CPU and the display processor 
can access the Irame buffer memory and share the graphics operation overhead, thereby improving graphics perform- 
ance Clearty. an implementation of the present invention in such a SAS system cannot rely on the premise that the 
buffer memory is safe during signing, since the CPU can still access the memory However, there are many ways in 
which such a SAS system may be modified to support implementations of the present invention. For example, the 
memory could be provided with a control line from a trusted display processor such that, during a signing operation, 
the memory is prevented from being updated by data from the CPU. The memory devices themselves are preferably 
modified so that they include the extra logic to perform this function. Alternatively, access to memory sbtockedby 
other logic circuits inserted into the normal control path of the memory. Such systems, therefore, rely on the modified 
premise thatthevideo data in theframe buffer memory canonly be modified, otherthanbythe trusted display processor, 
with the permission of the trusted display processor. Clearly, this premise is as valid tor secure operation as the first 
premise, as long as the system is truly secure. 

[0104] In other architectures, for example m simple graphics environments, the functionality of a display processor 
may lorm part ol me cperatng system HseH. ther^^ ^ 
Clearly in this case, the graphics overhead put on the CPU will be higher than in a system with separate disptey 
processor hardware, thereby limiting the graphics performance of the platform. Clearty, there is then no place tor a 
•trusted display processor 1 as such. However, It will be apparent to the skilled person that the same function as provided 
20 by the trusted display processor, that of protecting the frame buffer memory and interacting with a smartcard. can be 
implemented using an appropriate trusted component, which controls the display system (in whatever form) during 

[01O5] 9 In other embodiments of the invention, in addition or alternatively, the trusted display processor (or equivalent) 
includes an interface tor driving a trusted display. The trusted display might be. for example, an LCD panel displey. In 

.?5 the same way that the trusted switch provides a trusted moans tor a user to interact with the trusted display processor; 
the trusted display can provide a trusted means for feeding back information to the user other than via the standard 
VDU For example, the trusted display might be used to provide user status messages, as described above, relating 
to a signing operation. As such, applications running on the standard host computer should not be able to access the 
trusted display, because the display is connected either directly to the trusted display processor or via some form of 

30 trusted channel. In essence, such a trusted display is an addition to the soolled trusted interface' described above. 
In practice there is no reason why other forms of trusted feedback device, ot which the trusted display is one example, 
could not be included in addition, or as an alternative. For example, there may be scenarios where some form of trusted 
sound device would be useful for providing audible feedback. 
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Claims 



A data processing system arranged to generate a digital signature representative of a document, the data process- 
ing system comprising; 



main memory means for storing a document to be digitally signed; 
main processing means for executing at least one application process comprising means to generate graphics 
signals for displaying the document; 

means for generating a request signal tor the document to be signed; 
*s a display system comprising: 

frame buffer memory; 

means lor generating digital image data representative of the document on the basis of the graphics 
signals and storing the digital image data in the frame butler memory; and 
f o means for reading the digital 'mage data from the frame bufler memory, converting the data into signals 

suitable for displaying an actual image thereof on a display means and forwarding said signals to a display 
means; and 

a trusted component comprising independent processing means operable, in response to receipt of the request 
ss signal, tor generating a digital signature representative of the digital image data. 

2. A data processing system according to claim 1 . wherein the trusted componenl comprises means for denying to 
any unauthorised application or process write access to at least the portion of the frame buffer memory containing 
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the digital image data of the document, and means for generating a digital signature represente^e of the digital 
i^JdtnSa the respective portion of me frame buffer memory is not accesstote for wrmng data to. 

.. t ^ M ^ %rn 4 or piajm o further comprising a removable token comprising 

digital signature. 

eufilom arrnrHinn to ^ on© 0 f the preceding claims, wherein the trusted component further 
to highlight the displayed document image using the trusted image data. 

5 Ad ataprocessingsys.emaccord^^ 

ative of the trusted image or instructions for forming the trusted image. 

c A data nrocessing system according to claim 4 or claim 5. wherein the trusted component controls the ^ display 
sySm !o hTgS L dispiayed document image by producing one or more of the f oHowmg visual effects. 

a border or an indicator or indicators defining a border, characterised by the trusted image and positioned at 

ml^cteracterised by the trusted image formed within the document image; andtor 

a text message characterised by the trusted image formed with* or near the document image. 

7 Adatapr<«essings y stemaccc*ingto^ 

for acquiring and/or generating trusted image data from a removable token. 

8 A data processing system acting to any one of the preceding claims, wherein the trusted component further 
' comprises means tor controlling the display system to display messages to a user. 

9. Adata processing system according toclaim 8. further comprisingtrusted inputmeans by which auser can respond 
to messages in a secure fashion. 

10. A data processing system according to claim 9. wherein the trusted input means comprises a switch connected 
to the trusted component via a secure communications channel. 

11. A data processing system accoiding to daim 3 or claim 7. wherein the trusted component and the secure token 
enact a mutual authentication process in advance of further interactions. 

12. A data processing system according to any one of the preceding claims, wherein the trusted component forms an 
integral part of the display system. 

13 A data orocessing system according to claim 12. wherein the display system is arranged such that the trusted 
and luncttonally positioned between the main processing means and the frame buffer 
m^ such Sfi ICrocessing^means can only access the frame buffer memory indirectly through func 
lions of the trusted component. 

14. A data processing system according to any one ol the preceding claims, further comprising means lor generating 
data summarising a digital signature operation. 

15. A method lor digitally signing a document, comprising the steps: 

nenotttino dioital image data of the document and updating the digital image data in a frame buffer memory; 
£C£ tf£ ^ data from the frame buffer memory, converting the digital mage data into signals 
2 tor dSg 13,1 display means and transm^g the signals to a visua. display means for d.splay.ng 

2 d3d. 'reader dig^age data from the frame buffer memory and generating a digila. signature 
representative thereof. 
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16. A method according to claim l's, further comprising the step of temporarily denying write access to the frame buffer 
memory by unauthorised processes while generating the digital signature. 

17. A method according to claim 14 or claim 15, further comprising the step of acquiring and/or generating trusted 
5 image data and using the trusted image data to highlight the document image. 

18. A method according to claim 17, wherein step of highlighting the document image is achieved by generating any 
one or more of the following visual effects: 

io a border, or an indicator or indicators defining a border, characterised by the trusted image and positioned at 

least partly around the document image; t 
a background pattern characterised by the trusted image forming at least part of the background of the doc- 
ument image; 

an image characterised by the trusted image formed withh the document image; andtor 
is a text message characterised by the trusted image formed within or near the document image. 

19. A method according to claim 17 or claim 18, wherein the trusted image data is acquired from a removable token. 

20. A data processing system arranged to digitally sign a document in accordance with any one of claims 15 to 19. 

20 

21. A method for digitally signinga document comprising a plurality of individual viewable pages, comprising the steps: 

a) generating digital image data of the first page of the document and updating the digital image data in a 
frame buffer memory; 

2S b) reading the digital image data from the frame buffer memory, converting the digital imago data into signals 

suitable for driving a visual display means and transmitting the signals to a visual display means for displaying 
an image of the document; 

c) reading the digital image data from the frame buffer memory, generating a digital signature representative 
thereof and storing the digital signature; 
30 iv) repeating steps a) to c) for the other page(s) of the document; and 

v) generating a further digital signature representative of all previous digital signatures. 

22. A method for a second user to digitally counter-sign a document that has already been signed by a first user, the 
document being accompanied by a respective first digital signature generated by using a secret of the first user, 

35 comprising the steps: 

generating digital image data of the document and updating the digital image data in a frame buffer memory; 
reading the digital image data from the frame buffer memory, converting the digital image data into signals 
suitable tor driving a visual display means and transmitting the signals to a visual display means for displaying 
<o an image of the document; 

verifying the integrity of the first digital signature; and 

on the basis of a secret of the second user, generating a digital signature representative of the first digital 
signature. 

45 23. A method for a second user to digitally re-signing a document that has already been signed by a first user, the 
document being accompanied by a respective first digital signature generated by using a secret of the first user, 
comprising the steps: 

generating digital image data of the document and updating the digital image data in a frame buffer memory; 
so reading the digital image data from the frame buffer memory, converting the digital image data into signals 

suitable for driving a visual display means and transmitting the signals to a visual display means for displaying 
an image of the document; 

verifying the integrity of the first digital signature; and 

reading the digital image data from the frame buffer memory and, on the basis of a secret of the second user, 
ss generating a digital signature representative of the first digital signature. 

24. A data processing system arranged to generate a digital signature representative of a document, the data process- 
ing system comprising; 
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main processing means for generating graphics signals for display^ a document; 
a display system comprising: ' , 

l ra l*:S *mi image data representative of the ctocument on the basis of the 8 raph*s 
cinnaiQ and siorina the digital imaqe data in the Irame buffer memory; ana 

me^ns image data Irom the frame buffer memory, converting the data Wo sjgnals 

Se^ 
means; and 

means for generating a digital signature representative of the digital image data. 

25. A system for digitally signing a document comprising: 

Sir reading the image data from the frame buffer memory and displaying a respective image on a 
^TSSTu* image dala from the frame buffer memory and generating a digital signature thereoL 

26. A trusted component for use in a data processing system according to any one of claims 1 to 14. 

27. A trusted component according to claim 26, fabricated to be tamper resistant. 
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